Bridging Agile and Traditional Development Methods : A Project Management Perspective

T his article was motivated by a case study where a small company using a well-known agile method – eXtreme Programming (XP) – requested help addressing specific conflicts that arose on the project where they were a subcontractor to a larger organization employing a traditional development method. The purpose of this article is not to compare agile and traditional methods, but to raise awareness of potential project management conflicts that can arise when a company employing an agile method collaborates with a company employing a traditional development methodology. It also identifies practical steps that can be taken to reduce related risks. It is worth noting that the case study presented is not unique. Published references documenting similar conflicts are provided. Also notable is that the motivation for examining this project extends beyond the case study itself. Today there exist increasing opportunities for small companies to gain new work through software outsourcing from traditional development organizations. In this article, I first identify key case study facts along with relevant information and common misperceptions related to traditional and agile methods. Next, I identify four conflicts observed along with five recommendations and one lesson learned. The company named SubComp refers to the subcontractor employing an agile methodology. The company named PrimeComp refers to the prime contractor employing a traditional development methodology. Shortly before I was asked to help SubComp, PrimeComp's customer had withheld a progress payment based on a perceived risk observed at a recent critical design review (CDR). Written comments provided to PrimeComp indicated that the customer wanted to see working software in order to assess the proposed design and related risk. The area of concern was SubComp's responsibility. Upon receiving the customer comments, PrimeComp requested that SubComp provide additional detailed design documentation. It is important to note that PrimeComp required all correspondence between the customer and SubComp to go through them. It is also important to note that most of the contractually required documentation was not formally due until the end of the project, and, prior to the CDR, little had been communicated to SubComp with respect to documentation content and expectations. The project was planned using a traditional waterfall life cycle with a single CDR. Early in the project, SubComp had identified multiple technical risks. However, it had decided in the early stages to focus its small agile team on a single technical risk that it had assessed to be …